Shared repository of simulation models

ABSTRACT

A system simulates a process entity. Software instructions stored on a memory device and executable by a processor create a plurality of entity type objects that generically represents a type of process entity. Instructions store the plurality of entity type objects in a shared repository. Additionally, instructions enable a plurality of users to access the plurality of entity type objects in the shared repository simultaneously.

CROSS REFERENCE TO RELATED APPLICATION

This application claims the benefit of U.S. application Ser. No.61/890,730, filed Oct. 14, 2013, the disclosure of which is herebyincorporated by reference in its entirety for all purposes.

BACKGROUND

Aspects of the present invention generally relate to the fields ofnetworked computerized industrial control, automation systems andnetworked computerized systems utilized to monitor, log, and displayrelevant manufacturing/production events and associated data, andsupervisory level control and manufacturing information systems. Suchsystems generally execute above a regulatory control layer in a processcontrol system to provide guidance to lower level control elements suchas, by way of example, programmable logic controllers or distributedcontrol systems (DCSs). Such systems are also employed to acquire andmanage historical information relating to such processes and theirassociated output. More particularly, aspects of the present inventionrelate to systems and methods for using tools employing calculationsthat are designed model and simulate the process in order to optimizethe process. The use of these modeling and simulation functions allows auser to capture the economic benefit from processes such as refinery,chemical or petrochemical plant operations.

Industry increasingly depends upon highly automated data acquisition andcontrol systems to ensure that industrial processes are run efficiently,safely and reliably while lowering their overall production costs. Dataacquisition begins when a number of sensors measure aspects of anindustrial process and periodically report their measurements back to adata collection and control system. Such measurements come in a widevariety of forms. By way of example, the measurements produced by asensor/recorder include: a temperature, a pressure, a pH, a mass/volumeflow of material, a tallied inventory of packages waiting in a shippingline, or a photograph of a room in a factory. Often sophisticatedprocess management and control software examines the incoming data,produces status reports, and, in many cases, responds by sendingcommands to actuators/controllers that adjust the operation of at leasta portion of the industrial process. The data produced by the sensorsalso allow an operator to perform a number of supervisory tasksincluding: tailor the process (e.g., specify new set points) in responseto varying external conditions (including costs of raw materials),detect an inefficient/non-optimal operating condition and/or impendingequipment failure, and take remedial actions such as move equipment intoand out of service as required.

Typical industrial processes are extremely complex and receivesubstantially greater volumes of information than any human couldpossibly digest in its raw form. By way of example, it is not unheard ofto have thousands of sensors and control elements (e.g., valveactuators) monitoring/controlling aspects of a multi-stage processwithin an industrial plant. These sensors are of varied type and reporton varied characteristics of the process. Their outputs are similarlyvaried in the meaning of their measurements, in the amount of data sentfor each measurement, and in the frequency of their measurements. Asregards the latter, for accuracy and to enable quick response, some ofthese sensors/control elements take one or more measurements everysecond. Multiplying a single sensor/control element by thousands ofsensors/control elements (a typical industrial control environment)results in an overwhelming volume of data flowing into the manufacturinginformation and process control system. Sophisticated data managementand process visualization techniques have been developed to handle thelarge volumes of data generated by such system.

Due to this complexity, it is a difficult but vital task to ensure thatthe process is running efficiently. Although the modeling the processfor the purpose of simulating it is known, the challenges involved increating and using a simulation model of a process include ensuring theaccuracy of the model and responsive performance of the simulation whilerunning. Simulation of a process requires solving large systems ofequations, which can be extremely time consuming.

SUMMARY

Aspects of the present invention involve a system that models theprocess for the purpose of simulating it accurately. The simulation canbe used to locate any inefficiency in the current process and determinealterations that can improve or eliminate inefficiencies.Advantageously, aspects of the present invention ensure the accuracy ofthe model and responsive performance of the simulation while running.Moreover, such aspects facilitate the solving of large systems ofequations.

In one aspect, a system simulates a process entity. Softwareinstructions stored on a memory device and executable by a processorcreate a plurality of entity type objects, the entity type objectsgenerically representing a type of process entity. Instructions storethe plurality of entity type objects in a shared repository.Additionally, instructions enable a plurality of users to access theplurality of entity type objects in the shared repositorysimultaneously.

Software instructions stored on one or more tangible, non-transitorycomputer-readable media and executable by a processor embody furtheraspects of the invention. In yet another aspect, a processor executablemethod is provided.

Other objects and features will be in part apparent and in part pointedout hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram depicting a shared repository that stores models,simulations, and UOM (Units-of-Measure) slates according to anembodiment of the invention.

FIG. 2 is a diagram depicting model libraries within the sharedrepository of FIG. 1.

FIG. 3 is a diagram depicting the interaction between a model editor anda model type and the model library of FIG. 2.

FIG. 4 is a diagram depicting the interaction between a fluid editor anda fluid type, and the model library of FIG. 2.

FIG. 5 is an exemplary screenshot illustrating a fluid editor screenaccording to an embodiment of the invention.

FIG. 6 is an exemplary screenshot illustrating a model editor screenaccording to an embodiment of the invention and used to configure amodel type.

FIG. 7 is an exemplary screenshot illustrating a canvas where asimulation is being built with available model types in a model libraryaccording to an embodiment of the invention.

FIG. 8 is a diagram depicting the interaction between a port editor anda port type, and the model library of FIG. 2.

FIG. 9 is an exemplary screenshot illustrating a property inspectorscreen used to observe details about models in a simulation according toan embodiment of the invention.

FIG. 10 is an exemplary screenshot illustrating a trend manager screenused to observe and configure the tracking of variable trends duringsimulation according to an embodiment of the invention.

FIG. 11 is a diagram depicting the use of a connector in connecting asource model to a sink model according to an embodiment of theinvention.

FIG. 12 is a diagram depicting the relationship between Units of Measure(UOM) Slates and Model Types according to an embodiment of theinvention.

FIG. 13 is an exemplary screenshot illustrating the UOM slate of FIG. 1storing default units for use with a list of variables.

FIG. 14 is a diagram depicting the contents of a simulation snapshotaccording to an embodiment of the invention.

FIG. 15 is an exemplary screenshot illustrating a snapshot manager formanaging snapshots and reverting to previously stored snapshotsaccording to an embodiment of the invention.

FIG. 16 is an exemplary screenshot illustrating a simulation being builtat a first zoom level according to an embodiment of the invention.

FIG. 17 is an exemplary screenshot illustrating the simulation of FIG.16 at a greater zoom level.

FIG. 18 is an exemplary screenshot illustrating the use of the modeleditor of FIG. 2 to configure what data is displayed for a model, whereit is displayed, and at which zoom levels is it displayed.

FIG. 19 is a diagram depicting an exemplary process with included setsof equations that accurately reflect the behavior of each modelaccording to an embodiment of the invention.

FIG. 20 is a diagram depicting the process of FIG. 19 with some of thevariables highlighted that need to be specified for the system ofequations to be solvable in process design mode according to anembodiment of the invention.

FIG. 21 is a diagram depicting the process of FIG. 20 with the inclusionof sizing equations.

FIG. 22 is a diagram depicting the process of FIG. 20 with the specifiedvariables changed to reflect the change in mode, which is now in fluidflow mode.

FIG. 23 is a diagram depicting the process of FIG. 20 with the specifiedvariables changed to reflect the change in mode, which is now beinginitialized for dynamic mode.

FIG. 24 is a diagram depicting the process of FIG. 20 with the specifiedvariables changed to reflect the change in mode, which is now in dynamicmode.

FIG. 25 is an exemplary flowchart depicting the process of analyzing andsolving the system of equations and displaying solvability status to theuser according to an embodiment of the invention.

FIG. 26 is a diagram depicting an exemplary system diagram comprisingbasic process elements.

Corresponding reference characters indicate corresponding partsthroughout the drawings.

DETAILED DESCRIPTION

Aspects of the invention relate to a three-mode simulator softwareprogram capable of steady state mass and energy balances, fluid flownetwork analysis, and dynamic Simulation (Process, Fluid Flow, andDynamics modes, respectively) within a single Simulation Model.Advantageously, the program is more powerful but easier to use thancurrent specialized tools, and allows greater convenience andcollaboration through new computing technology. The simulation programembodying aspects of the invention further allows engineers to designand share complex process simulation models. And the program allows themodification of existing Model Types and creation of custom Model Typesfor new processes, organizes Models in Model Libraries for sharing withother users, and defines Variables and Equations in Models thatrepresent chemical process Models. Moreover, the simulation programembodying aspects of the invention stores Model Libraries, Simulations,and Units of Measure (UOM) slates in a Repository, allowing them to beshared among users.

Referring first to a Repository feature according to an embodiment ofthe simulation program, FIG. 1 shows a diagram of a Repository Manager100. The Repository 102 is where Simulations 104, Model Libraries 108,and UOM slates 106 are stored. The Repository 102 can be stored on alocal machine, or on a shared server. The simulation program managesaccess to the Repository's Simulations 104 through the RepositoryManager 100. The information housed in Repository 102 is current andalways accessible by any users (User A, generally indicated at 110, andUser B, generally indicated at 112) working within the same Repository102.

Multiple users 110, 112 can access Repository 102 at the same time. Andthrough the Repository 102, they can easily share information betweeneach other having to do with the various entities (Simulations 104,Model Libraries 108, and UOM slates 106) that are stored on Repository102. Preferably, changes that a user makes to an entity stored onRepository 102 are automatically persisted to the Repository 102 so thatother interested users can make use of the newest version of the changedentity.

Because simulations 104 stored on Repository 102 are available tomultiple users simultaneously, more than one user and users in differentlocations can work with the same simulation 104 simultaneously. Thisallows for easy collaboration between users, even if the users are indifferent locations.

The Repository 102 allows for users to import entities to and exportentities from Repository 102. For instance, a user could export a newlycreated simulation 104 from Repository 102 for the purpose of sharing itwith other users who are using a different Repository. In the same way,a user can receive a new entity from outside Repository 102 and importit into Repository 102 to allow all the users of that Repository 102 useof the new entity.

When a change is made to a Model or Simulation, it is automaticallysaved to the Repository. In addition to automatically saving work, therepository can also store Snapshots of a simulation and its objectscreated by a Snapshot Manager. A Snapshot is an archive of the state ofthe Simulation at a previous solution. It contains all Variable and RealParameter values and the Variables' specification status. The SnapshotManager can create a new Snapshot or return to a previous one. TheSnapshot Manager is used to add a description to a Snapshot, rename aSnapshot, delete a Snapshot and more. When a Snapshot is created, it issaved with the Simulation.

In FIG. 2, reference is made to a Model Library feature and a diagram200 of the Model Libraries 204 within a Repository 202 is shown. TheModel Library 204 is where Model, Fluid and Port Types 214 are stored.The Model Library 204 is housed within the Repository 202 on a sharedserver or on a local machine. Multiple people (e.g., User A, generallyindicated at 210, and User B, generally indicated at 212) can accessModel, Fluid and Port Types 214 from and save them to a Model Library204 in a shared Repository 202. Model libraries 204 can be accessed tobuild a single Simulation 104. One of the key benefits of the ModelLibrary 204 is that a user can work with other people to create andshare custom, company-specific Model Types 214 that contain proprietaryEquations. The information housed in Model Library 204 is current andalways accessible by users working within the same Repository 202.

Model Types, Fluid Types, and Port Types 214 stored in the ModelLibraries 204 behave as templates, or generic representations of thetype of entity that they describe. Flowsheets are simulation objects andare defined only in simulations. Flowsheets are containers for instancesof model types that the user creates when building a simulation. When amodel is placed on a flowsheet an instance of the type is created. Everymodel instance stores its type. For instance type “Pump” would be foundas a custom model inside the simulation (no prefix). However, type“SimSci.Pump” would be the standard Pump type in the Simsci library.

Model Libraries 204 normally are separate from simulations and live inthe repository 202. The default library 206 that comes with the installis the “SimSci” library. This is where standard model types, port types,and fluid types 214 are stored. Libraries found in the repository willbe known as Repository Libraries. Custom Model Libraries 208 can becreated (by project teams or customers), imported, exported and sharedbetween users. Each simulation also contains an internal model library.This is where model types private to a simulation can be defined. Theinternal model library is still considered a library, even though it isowned by the simulation.

Because the Model Library 204 is stored in Repository 202, it can beaccessed by multiple users 210 and 212 simultaneously. A Shipped ModelLibrary 206 may be populated with standard Model, Fluid, and Port types214, or a user could create his or her own Custom Model Library 208 andpopulate it with custom created types 214.

The types 214 stored in Model Library 204 can be used to create asimulation, which is also stored on Repository 202. A user can make useof multiple Model Libraries 204 while creating a single simulation. Thisgives the user great flexibility in selecting the proper types to use inthe simulation. A user can also copy Model, Fluid, or Port Types 214from one Model Library 204 to another.

When a user edits a Model Type, Port Type, or Fluid Type 214 referencedby a Simulation, the changes are automatically saved to both ModelLibrary 204 and Repository 202, and are immediately reflected in theSimulation. This allows a user to easily propagate changes throughoutmany simulations without having to make the change in each simulation.

The Repository 202 allows for users to import Model Libraries 204 to andexport Model Libraries 204 from Repository 202. For instance, a usercould export a newly created Model Library 204 from Repository 202 forthe purpose of sharing it with other users who are using a differentRepository. In the same way, a user can receive a new Model Library 204from outside Repository 202 and import it into Repository 202 to allowall the users of that Repository 202 use of the new Model Library 204.

FIG. 3 illustrates a Model Editor feature according to an embodiment ofthe invention. FIG. 3 shows the relationship between a Model Editor 306and a Model Library 304. The Model Editor 306 is where a user createsand modifies Model Types 308 representing process equipment, controls,and other mathematical relationships. A user can create custom,company-specific Model Types 308 that include proprietary Equations 318and save them to the Model Libraries 304 stored in a Repository 302. TheModel Editor 306 is used to define Variables 314 and Equations 318 inModel Types 308 that represent chemical process Models.

The Model Editor 306 defines new Model Types 308 or edits existing ModelTypes 308 to fit specific requirements. Even standard Model Types 308may be edited in this way, allowing for highly customizable Model Types308.

A user can use the Model Editor 306 to build a hierarchy of Model Types308, where complex Model Types 308 are built out of smaller Model Typesby adding them as Submodels 310. This allows a user to create custombuilding blocks that can greatly increase the efficiency of buildingcomplex systems.

Because Model Types 308 created or edited with the Model Editor 306 aresaved in Model Library 304 on the Repository 302, changes made to theModel Types 308 may be automatically saved to Repository 302 andpropagated to all simulations that reference the changed Model Type 308and are linked to the proper Repository 302 and Model Library 304.

The Model Type 308 created or edited in Model Editor 306 can be made upof a variety of data, including Sub-Models 310, conditions 312,variables 314, parameters 316, equations 318, and ports 320. Icons canbe associated with Model Types 308 as well.

Conditions 312 cause the creation, non-creation, or removal of affectedVariables, Equations, Models, and Ports. Furthermore, Conditions may bebased on integer or enumerated Parameters and must evaluate to aBoolean. Before a Condition can be added, a user must first create aninteger or enumerated Parameter. Conditions are evaluated when a ModelType is first placed on a Flowsheet, when a Parameter value is changed,and when a Model Type is modified in the Model Editor. By usingConditions in conjunction with Parameters, a user can create optional orconfigurable Model Type behavior.

When a new Condition is added to a Model Type or modify an existing one,a user writes a basic expression using conditional logic (equals, lessthan, greater than, less than or equal to, greater than or equal to, notequal, etc.). These groups of operators and functions are meant merelyas examples and do not limit the use of operators and functions that arenot listed.

A user can add a Variable 314 to a Model Type or Port Type in the ModelEditor or Port Editor, associate a Condition with it, and specify it forparticular Simulation Modes. Simulation Modes will be discussed ingreater length below. Choosing to specify a Variable for a particularSimulation Mode means that, when the system is solving an equation, thatspecified Variable is defined before solving the equation, rather thanbeing solved for with the equation. This allows a user to determine howdifferent Simulation Modes affect a Model Type and which variables needto be solved for in each Simulation Mode. Variables have a variable typethat determines what the variable measures and what units of measure thevariable uses.

A user can add Equations 318 to a Model Type to define mathematicalrelationships of variables within the Model. Equations mathematicallyrepresent the behavior of the entity that the Model is representing andthe act of solving the equations based on the specified variablesenables the system to accurately simulate the behavior of the actualsystem. When a new Equation is added to a Model Type or an existingEquation is modified, a user writes an expression using the mathematicaloperators (+, −, *, /, etc.) and a variety of other mathematicalfunctions (exponential, absolute value, square root, etc.). Equationsadded to a Model Type can include time derivative equations so that theModel can simulate dynamic behavior. There are also a variety ofmathematical functions that can be used (exponential, absolute value,square root, etc.). These groups of operators and functions are meantmerely as examples and do not limit the use of operators and functionsthat are not listed

A user can add a Model Type as a Submodel 310 of another Model Type 308.Submodels are beneficial as they provide the ability to create“template” Model Types that can be used as building blocks to createlarger and more complicated Model Types.

A user can add a Parameter 316 to a Model or Port Type. The simulationprogram according to embodiments of the invention allows Integer, Realand Enumerated Parameters. Real Parameters use the same Variable Typesas Variables. A Parameter is like a Variable, except that it is constantand defined within the Model. A Parameter may be included in an Equationon a Model, but it will always be defined based on what it is set to inthe Model Type, and the Parameter will never be solved for. Parameterscan be connected so that the value of one Parameter can be automaticallypropagated to another Parameter.

A user can add Port Types 320 to Model Type 308 to determine how theModel Type can connect to other Model Types in a simulation. Port Typeswill be explained in greater detail later.

The display of variables and parameters will also be configured in theModel Editor. The definition of the “icon” for the model type will beshown in a panel called “Icon”. New icons can be associated with a ModelType, Fluid Type or Port Type. The icon to be associated may be in theform of an Extensible Application Markup (XAML) file. Other icon formatsmay also be used.

In addition to configuring the icon, a user can also assign defaultpositions for the appearance of the name of the model and for theappearance of desired variables and parameters. Later, when the model isplaced into a simulation, a user can move the name or other field toanother position, which will be saved within the simulation itself. Thedefault locations of model name and other variables are saved in themodel library, and when changed in the model library, the new positionspropagate to each instance of the changed model type that is using thedefault position. Model instances that have a user-set position will notbe changed to reflect the new default position.

If a variable is added to a model type icon that is an array, the usercan add an index to display a single element. If an element number isnot added, then when the variable is displayed on the canvas the entirearray will displayed in a vertical column.

Some examples of standard Model Types are Source Models, Sink Models,Junction Models, Valve Models, and Pipe Models. The Source Model definesthe flow and thermodynamic state of a feed stream. In Process Mode, theSource Model specifies the pressure, temperature, and flow of thestream. In Fluid Flow and Dynamics Modes, the flow is typicallycalculated.

The Sink Model sets downstream pressure at boundary in all modes.However, for refinery steam systems, a user may use the sink to set flowrates to typical refinery steam consumers.

The Junction Model is a mixing and splitting Model that represents apiping tee with up to two feed ports and two product ports. It has nointernal volume and has no dynamic accumulation. It can be used to joinflow-based models such as pipes, valves, and turbines, or to split aflow to pipes, valves, turbines, or PSVs.

The Valve Model is a flow-based Model. It can model incompressible(liquid) flow or compressible (vapor) flow including choked flow. InProcess Mode, it will determine pressure drop and Cv given a known flowrate and known pressure difference. In Fluid Flow and Dynamics Mode, itwill determine the flow given a known Cv and pressure difference.

The Pipe Model is a flow-based equipment Model. It uses aconstant-density Darcy equation designed to model pipes with moderatepressure drop. As the pipe is made up of two internal Darcy equationSubmodels with a density calculation in the middle, it can be used forup to 20% pressure drop. If the pressure drop is greater than 20%,multiple pipes in series should be used. By default, the pipe diametercan be estimated given a specified fluid velocity. An optional scheduleof nominal pipe sizes can be enabled so that an actual pipe diameter canbe fixed from the table. In Fluid Flow and Dynamics Modes, the pipe willdetermine the flow given a specified equivalent length, diameter andknown pressure difference. In Dynamics Mode, the Model will determinetransient pressure behavior based on the volume of the pipe andaccumulation of fluid within it.

Model Types 308 may also have an inheritance feature that allows a userto create a new Model Type that extends an existing Model Type. This newModel Type would inherit all of the characteristics of the alreadyexisting Model Type, but the user could add new characteristics on tothe new Model Type without altering the existing Model Type. In thisway, users can include custom variables, parameters, and equations intheir Model Types to better represent their particular system.

FIG. 4 shows a diagram 400 of the relationship between a Fluid Editor406 and a Model Library 404 according to an embodiment of the invention.The Fluid Editor 406 modifies Fluid Types 408 representing the fluidsused in the environment. The Fluid Type 408 describes the thermodynamicbehavior assigned to Model Instances in a Simulation. Existing FluidTypes 408 are copied and edited to create custom Fluid Types 408 thatinclude the default pressure and temperature (Starting Values 410) ofthe fluid to be emulated and a fluid classification 412 which definesequations to be used to calculate behavior of the fluid. The customFluid types 408 are saved to Model Libraries 406 stored in a SimCentralRepository 402. The Fluid Editor 406 also defines a custom icon 414 forthe Fluid Type 406.

Because Fluid Types 408 created or edited with Fluid Editor 406 aresaved in the Model Library 404 on the Repository 402, changes made tothe Fluid Types 408 may be automatically saved to Repository 402 andpropagated to all simulations that reference the changed Fluid Type 408and are linked to the proper Repository 402 and Model Library 404.

The Fluid Editor 406 defines new Fluid Types 408 or edits existing FluidTypes 408 to fit specific requirements. Even standard Fluid Types 408may be edited in this way, allowing for highly customizable Fluid Types408.

FIG. 5 shows an example of a dialog box 500 that may be used to create anew Fluid Type or modify an existing Fluid Type. A user can name a FluidType 510 and give it a description 512 in a General tab 502, give itstarting values for pressure 514 and temperature 516 variables in theStarting Values tab 504, and choose a fluid classification 518 in aConfiguration tab 506, which defines which equations are used torepresent the behavior of the fluid. There is also an Icon tab 508 forconfiguring an icon as described above.

FIG. 6 shows a dialog box 600 that is representative of the Model Editorfor editing a Model Type as described above. A user can observe orchange the details of the Model Type, including the general information,like the name of the Model Type and the description of a Model Type 602.There is a section that shows the parameters of the Model Type 604, theconditions that affect a Model Type behavior 606, and internal equationsthat define the Model Type behavior 608. In addition, a user can use the“external” section to link to equations that might be external to aModel Type 610. Finally, there is an Icon tab for configuring the iconassociated with a Model Type 612.

FIG. 7 shows an example of a flowsheet being built on a canvas 702 and apalette 704 to the left side that shows available fluids for use in thesimulation (Air, CoolingWater, Steam). A user takes a fluid from theleft side and associates it with the models in the canvas (Source1 708,Valve1 710, Sink1 712, etc.). The Source1 708 is a model that definesthe characteristics of the Fluid as it enters the flowsheet and theSink1 712 is a model that receives the fluid as it flows out of theflowsheet. The Valve1 710 is an exemplary model that interacts with afluid. While this example is very simple, a flowsheet could contain manydifferent interconnected models that interact with the Fluid in myriadways. To the right, a hierarchical tree 706 displays information aboutthe simulation being viewed/edited. In this case, it shows a model“Source1” which is using the “CoolingWater” fluid along with data aboutthe model. The simulation would then simulate the behavior of the chosenfluid through the models on the canvas.

FIG. 8 illustrates a Port Editor feature of the simulation programembodying aspects of the invention. A diagram 800 displays therelationship between a Port Editor 806 and a Model Library 804. The PortEditor 806 creates and edits Port Types 808, which are used inside ModelTypes to define how the Model can be connected to other Models on theCanvas. Port Types also inherit much of the structure of Model Types asdefined above. When new Model types are created, the Fluid Port Types808 included with the simulation program in accordance with aspects ofthe invention can be used to define input and output Ports used forprocess stream connections. If no suitable Port Type exists, an existingPort Type 808 can copied and edited to be compatible. During editing,Port Type name is specified, Variables 812 and their types arespecified, the Canvas connection (line) style 810 is determined, adescription is included, and an Icon 814 is determined. The Variables812 defined in the Port Type 808 define the specific information thatwill be transferred between Models when they are connected on theCanvas. Once a Port Type 808 is defined, the Model Editor can use thosePort Types to add Ports to Model types. Connections between Models onthe Canvas can only be made between Ports of the same type. Ports 808are saved in the Model Libraries 804, which are stored in a SimCentralRepository 802.

Because Port Types 808 created or edited with Port Editor 806 are savedin Model Library 804 on the Repository 802, changes made to the PortTypes 808 may be automatically saved to Repository 802 and propagated toall simulations that reference the changed Port Type 808 and are linkedto the proper Repository 802 and Model Library 804.

The Port Type 808 created or edited in Port Editor 806 can be made up ofa variety of data, including conditions, variables 812, parameters, andconnector line characteristics 810. Icons 814 can be associated withModel Types as well.

Conditions cause the creation, non-creation, or removal of affectedVariables, Equations, Models, and Ports. Furthermore, Conditions may bebased on integer or enumerated Parameters and must evaluate to aBoolean. Before a user can add a Condition, an integer or enumeratedParameter must be created. Conditions are evaluated when a Model Typecontaining a Port Type is first placed on a Flowsheet, when a Parametervalue is changed, and when a Port Type is modified in the Port Editor.By using Conditions in conjunction with Parameters, a user can createoptional or configurable Model Type behavior.

A user can add Variable 812 to a Port Type in the Port Editor, associatea Condition with it, and specify it for particular Simulation Modes.Simulation Modes will be discussed in greater length below. Choosing tospecify a Variable for a particular Simulation Mode means that, when thesystem is solving an equation, that specified Variable is defined beforesolving the equation, rather than being solved for with the equation.This allows a user to determine how different Simulation Modes affect aPort Type and which variables need to be solved for in each SimulationMode. Variables have a variable type that determines what the variablemeasures and what units of measure the variable uses.

If a variable is added to a port type icon that is an array, the usercan add an index to display a single element. If an element number isnot added, then when the variable is displayed on the canvas the entirearray will displayed in a vertical column.

In an embodiment, Simulation Manager is a hierarchical view of theSimulation and the Models contained within it. The Simulation Managerprovides a hierarchical view of a Simulation, including models,connectors, and their submodels and ports. In addition, the SimulationManager allows the addition of variables, parameters, and equationsdirectly to the main flowsheet. The Keyword View enables viewing andediting objects selected in the Simulation Manager. When selecting aSimulation object in the Simulation Manager, the Keyword View displays adetailed view of the selected object and enables editing of specificVariables and Parameter values.

Further, Simulation Canvas enables a user to build a visualrepresentation of the Simulation. A user drags Model Types from theModel Library onto the canvas, connects the Models using Connectors andPorts and adds a Trend and Variable references to the Canvas. A userspecifies Variables and enters values, views the state of Equations,modifies Variable and Parameter values, and adds Trends. Changes made inthe Simulation manager are automatically reflected in the otherapplication views and on the Simulation Canvas.

FIG. 9 shows an exemplary screenshot of a Property Inspector 900. TheProperty Inspector 900 displays and edits Models from the Canvas. TheProperty Inspector 900 also sorts and groups Variables and filtersVariables and Parameters. In the screenshot, tabs can be seen fordifferent groups, including Variables 902, Parameters, and General. Eachof these tabs can be expanded and collapsed to allow for viewing andediting of the grouped information therein. The Variables tab 902 isopen and displays the variables 904 associated with a particular Modelcalled ControlValve2. The group of variables 904 shows a variety ofinformation about each variable, including Name, Value, Units, Model,Description, and Status Badges.

The Property Inspector 900 is accessed by double-clicking a Model on theSimulation Canvas, or by right-clicking a Flowsheet or Model on theSimulation Manager and selecting Properties from the context menu.Changes made in the Property Inspector 900 propagate automatically tothe other parts of the User Interface, including the Simulation Managerand the Simulation Canvas. The Property Inspector 900 allows forVariables to be sorted or grouped for easier navigation of complexsystems.

Trends can be added to Simulations. Trends plot the time history of aVariable in Dynamics mode. The Trend Manager manages Trends in thesimulation program. FIG. 10 shows an exemplary screenshot of a TrendManager window 1000. The window 1000 contains several different sectionsfor observing and configuring trends. A first section 1002 shows avisual representation of a trend line. As an example, section 1002 showsa timeline with time measured in seconds on the horizontal axis. In anAxes section 1004, names and limits may be configured for the axes ofthe trend graph shown. In a Variables section 1006, the variables beingmonitored on the trend graph can be configured, including setting theirminimum and maximum values as well as line colors. The configure section1008 allows configuration of the trend graph grid itself. Trend look andfeel can be modified and changes are automatically saved and displayedon the Trend chart.

A user can check that a Simulation and its components are solved via theSolution Status section on the Ribbon, the Simulation Manager, and theProperty Inspector. A user can check a Solution Status section of theProcess tab to check if the Simulation currently displayed on the Canvasis solved. As the Simulation is analyzed and solved as a whole, theSolution Status indicates whether the simulation contains user-enteredvalues for all the required data, whether the simulation is propertyspecified (“square”), and whether the solution is solved. More detailsabout how a solution is solved are described below.

Specific Parameters and Variables can be filtered in the PropertyInspector or Keyword View to include or exclude information in aSimulation. When a filter is set, the filter is saved and automaticallyloaded when the simulation program is launched.

To convey information in an intuitive, non-intrusive way, the simulationprogram embodying aspects of the invention dynamically badges parts ofthe user interface. As a rule of thumb, green badges signify a good,solvable state or default data, blue badges signify that something hasbeen set or touched by a user, yellow badges indicate a warning stateand red badges mean that there is an error.

FIG. 11 displays an exemplary screenshot of a basic Connector 1104between Models 1102 and 1106 on a Simulation Canvas 1100. As a usermoves the mouse over the target Model 1102, the available Ports appear,highlighted. Moving the mouse to the target Port on Model 1106 andreleasing the mouse button completes the Connector 1104. The connectedModels can be repositioned after the connection is formed and theConnector 1104 will shift position along with the Models. Drag an end ofa Connector away from a model and release it to temporarily disconnect aConnector.

In an embodiment, the simulation program supports user and Simulationpreferences. User preferences can be changed, such as the SimulationCanvas background or display theme, and the selected preferences aresaved and maintained across different Simulations throughout thesimulation program.

Simulation preferences, such as choosing to display Model and connectorlabels, are saved on a per-Simulation basis; for example, if a userchooses to hide Model labels on Simulation A, but wants to display themon Simulation B, each preference will be saved in the Simulation towhich it applies.

The diagram of FIG. 12 displays the relationship between Model Types1202 and Unit of Measure (UOM) Slates 1204. Units of Measure (UOM)Slates 1204 are a collection of UOMs that are used for numerical displaywithin the user interface. Each UOM Slate defines a default UOM 1212 tobe used for each Variable Type 1210. UOM Slates 1204 can be created,modified, copied and deleted. Furthermore, preferred UOM Slates 1204 areselected for use in a Simulation, and the change will be reflected inthe numeric values displayed in the simulation program according to anembodiment of the invention.

Every Variable 1208 and Real Parameter in the simulation program isassociated with a Variable Type 1210, such as Pressure, Temperature andMass Flow. Every Variable Type 1210 has a permanent internal UOM 1212.Changes are made to a UOM 1212 in the Property Inspector or SimulationManager. Changes made to the UOM 1212 for a specific Variable 1208 arereflected in every instance of that Variable 1208, except for Variablereferences and Trends. Variable 1208 references and Ports will followthe UOM 1212 of the Variable 1208 until it is manually changed by theuser using the Simulation Manager, Property Inspector, or Keyword View.After a manual change, independent UOM selection is enabled and theselected UOM will take precedence.

FIG. 13 displays an exemplary screenshot of a UOM Manager 1300 forconfiguring a UOM Slate. In an embodiment, the simulation programprovides users with two UOM Slates, SI and US Refining, but a user cancreate their own custom UOM Slates. FIG. 13 shows the SI UOM Slate, ascan be seen in the Slate name area 1302. The UOM Manager also shows theSlate Description 1304 and each of the Variable Types 1306. EachVariable Type 1306 has a Display Unit and a Category. Variable Types1306 are organized by category for easier navigation during UOM Slatedefinition.

Using the UOM Manager, a user can add, modify, copy, and delete UOMSlates from the system. UOM Slates are stored in the Repositoryalongside the Model Libraries and Simulations. Changes made to UOMSlates may be automatically saved to the Repository and propagated toall simulations that reference the changed UOM Slate and are linked tothe proper Repository. UOM Slates can be saved on the Repository and mayalso be saved with specific simulations.

FIG. 14 displays a diagram 1400 describing a Simulation Snapshot 1402. ASnapshot 1402 is an archive of the state of the Simulation at a previoussolution. It contains all Variable values 1410 and Real Parameter values1406 and the Variables' specification status 1408 as well as CalculatedVariable Values 1412. The simulation program according to an embodimentof the invention creates Snapshots that allows a Simulation to return toa previous solution. For example, a Snapshot can be saved beforemodifying a Simulation by changing values or changing specifications.The saved Snapshot can be used to revert to the previous version of theSimulation in the event that the user wants to return to the previousset of specifications/values. Snapshot Data 1404 is stored within theRepository and associated with the specific Simulation from which it wascreated. In this way, Snapshots can be saved of particular states of aSimulation and then accessed by multiple users of that simulation.

FIG. 15 displays Snapshot Manager 1500. The Snapshot Manager 1500creates a new Snapshot or returns to a previous Snapshot. And SnapshotManager 1500 contains a single Snapshot 1502 named “Pro1” and describedas “Process Mode Snapshot”. The Snapshot Manager 1500 enables a user tochange the name and description among other details about a givenSnapshot. Using Snapshot Manager 1500, a Snapshot can be reset 1504,reverted 1506, or deleted 1510. The Special button 1508 enables moreadvanced Snapshot actions. A created Snapshot is saved with the relatedSimulation. Multiple Snapshots are created of the same simulation and aspecific Snapshot can be restored as desired. A user determines whattype of data to load upon Snapshot restoration. The Snapshot Manager1500 chooses Simulation Snapshot-specific settings to load for returningto a previous state. The Snapshot Manager 1500 is accessible from eachof the Mode tabs.

Referring now to FIG. 16, FIG. 17, and FIG. 18, when zooming in on thecanvas, model instances can display additional information as the zoomlevel increases. The specific information to be displayed is configuredby the model editor when building the model types. This is known as“semantic zoom”.

FIG. 16 displays an exemplary screenshot 1600 of a canvas 1602containing a plurality of models 1606 connected together to form asimple Simulation. The canvas 1602 is viewed at a particular zoom leveland at this zoom level, each model has an associated name 1608displayed. More models may be added to the canvas 1602 from the modelpalette 1604.

FIG. 17 shows a screenshot 1700 of the canvas 1602 from FIG. 16 with anincreased zoom level. As a result of zooming in, each of the models 1706on the canvas 1702 appears larger than in FIG. 16. Each of the models1706 still includes the associated name information and also includesadditional information 1708 about the model. For instance, under eachmodel, the temperature and pressure values associated with the model aredisplayed. When a user zooms in on a canvas and crosses a semantic zoomthreshold, additional data as shown here may be displayed in order togive the user additional information. When zooming out and crossing asemantic zoom threshold, the additional data is no longer displayed andthe model data will revert back to showing less data. By showing lessdata at a “zoomed out” level, a complex simulation may be easier tounderstand as the view of the models is simplified.

FIG. 18 shows a screenshot 1800 of the Model Editor. The Model Editor isused to determine what information is displayed near a model on thecanvas. In the Icon section 1802, the icon 1806 representing the modelon the canvas is shown. Additional data 1808 is shown near the icon andwill be populated with the actual data values on the canvas, as seen inFIG. 17. In this case, the icon 1806 shows a valve with an input andoutput and three data fields 1808, including Name, a Fraction (A), andDifference Pressure (DP). The equivalent variables are shown below inthe Variable section 1804. The location where the data 1808 appearsaround the icon can be changed in the Icon section 1802. In this case,the data 1808 appears under the valve icon 1806, but it could be movedto appear above or to the side of the icon as well. The Variable section1804 enables a user to configure individual variables to appear atdifferent levels of zoom as shown in FIG. 16 and FIG. 17. In this case,the Name appears at all zoom levels and the Fraction and DifferentialPressure may only appear when zoomed in closely to the icon on thecanvas.

The specific zoom percentage can be changed by the user and are saved asa “user preference”. It will also be possible to set the “zoompercentage” for a specific canvas (just like current canvas backgroundcolor). This will allow each simulation being able to specify differentvalues.

When the semantic zoom values are displayed, a Simulation Builder canview/modify values and change the units-of-measure, the same as with“variable references”. At 100% zoom, the default zoom level, models andconnectors are shown in their default state. Show/Hide of labels is setby “Model Labels” and “Connector Labels” check boxes on the View tab ofthe Ribbon. As the user zooms in, the icons grow big but the textremains the same size. When the zoom level reaches the defined 200%level (or the user-entered alternate percentage as defined) the modelinstances are decorated with information as defined by the ModelDeveloper.

Using the “semantic display” features, the display is fully interactive;the user can modify the variable/parameter values and change theunits-of-measure, just like they can with the “variable reference”. Theexact position of the individual variables/parameters can be changed bythe user. If it is moved, the new position will be saved with thesimulation.

Standard propagation rules will apply: if a user changes the definition(variables/parameters shown) of the semantic zoom view, all modelinstances will be updated. If a user changes the position of avariable/parameter, then all model instances will be updated except forthose specific variables/parameters that have been changed and are nolonger in default positions.

The simulation program embodying aspects of the invention includes threeSimulation Modes: Process Mode, Fluid Flow Mode, and Dynamics Mode.Process Mode performs steady state Simulations to create and improveprocess design, Fluid Flow Mode is a steady state simulator that modelspiping networks and Dynamics Mode simulates system transients over time.A Simulation created in Process Mode, for example, can be switched toFluid Flow Mode by changing the Mode toggle.

Simulation Mode is toggled between Process, Fluid Flow and Dynamics Modeby selecting the desired mode in the application ribbon on the Process,Fluid Flow and Dynamics tabs, respectively. Process mode is selectedupon creation of a new Simulation. The Variable specification in theSimulation will automatically change upon switching Modes based on thedefault settings for each mode for each Model Type, as defined by theModel Library. The different Simulation Modes also include optionsrelevant to the mode selected; for example, the ability to automaticallysolve the simulation in Process Mode and go to a steady state in DynamicMode.

Process Mode performs steady state Simulations to create and improveprocess design. It is designed to perform mass and energy balancecalculations. Process Mode is selected on-the-fly under the Modesection. In Process Mode, the Variable specification of equipment in theSimulation will change according to the definition for each Model type.Fluid Flow Mode is a steady state simulator that models piping networks.Fluid Flow Mode can be selected on-the-fly under the Mode section. InFluid Flow Mode, the Variable specification of equipment in theSimulation will change according to the definition for each Model type.Dynamics Mode simulates system transients over time. Dynamics Mode canbe selected on-the-fly under the Mode section. In Dynamics Mode, theVariable specification of equipment in the Simulation will changeaccording to the definition for each Model Type.

The modes primarily affect the basic specification of the simulation:which variables are fixed or freed and which parameters, variables, andequations are active or inactive. In the final environment it may alsoaffect the preferred icons available in the icon palette and thespecific layers viewable by default.

The different modes have previously been handled by separate programs,such as PRO/II, ROMeo, and Dynsim. In the simulation program, it isdesired to have one application that can use one simulation model in allinterested modes. The general strategy for multiple mode support in thesimulation program is as follows:

-   -   i. The model developer defines the mathematical relationships        (equations) between the relevant process simulation variables.    -   ii. The user builds a simulation with these models. The user        will select a specific “mode” to be used, which implies that        some of the simulation variables will have fixed quantities,        with the remaining to be calculated.    -   iii. When the simulation is solved, the system will apply        standard mathematical solver techniques to solve the set of        equations and variables for the unknown variables.    -   iv. When the user changes to a different “mode”, this will        change the set of simulation of variables that will have fixed        quantities. With these new settings, a different set of unknown        variables will be solved for. The mathematical equations will be        unchanged.

FIG. 19 illustrates the above process using a diagram 1900 consisting ofa Source 1902, two valves V1 1906 and V2 1914, and a drum container D11910. Each of the elements in connected in a line using connectors S11904, S2 1908, S3 1912, and S4 1916. The mathematical equations applyingto the elements are created by the model developer and are shown belowthe icons. Equations 1918 apply to S1 1904 and the flow coming fromSource 1902. The equations applied to each element of the system can beany equations that closely represent the physical behavior orcharacteristics of the actual device or element being represented. Inthe case of Equations 1918, there are two equations that represent theenthalpy (H) and the fluid density (ρ) of the fluid that is flowing fromsource 1902 through connector S1 1904. The calculation of the values isnot specified in this example, but it is sufficient to know that bothvalues are calculated as functions of the temperature (T) and thepressure (P) of the fluid.

Equation set 1922 applies to the physical functionality of the valve V11906. The equation set 1922 contains five equations, some similar toequation set 1918. These similar equations and equivalence equations arecommon when dealing with elements that are connected by a stream offluid. Equation set 1923 applies to the physical functionality of thedrum container D1 1910, and once again there are several equationspresent in equation set 1923 similar to previous equations sets.Equation set 1924 applies to the physical functionality of the valve V21914. The equation set 1924 can be seen to be nearly identical toequation set 1922, which also applies to a valve. The only differencesare the connectors from which the various values are being drawn.

In a typical workflow, the user builds the simulation model first inProcess Design mode. This mode is typically be used for high-leveldesign (including mass/energy balance) and the solution is steady-stateand flow-driven. The user will typically specify the flowrate for thefeed stream, pressure drops across the valves, and duty for the drum.

FIG. 20 shows the same diagram as FIG. 19 but with several of thevariables in the equations bolded. The bolded variables are fixed orspecified variables needed for the steady-state, flow-driven ProcessDesign mode. There are 23 variables and only 17 equations, so six fixedvariables are needed so that the number of “free” variables matches thenumber of equations, enabling the solver to find a solution. When theuser provides values for these fixed variables the underlying solverwill then be able to solve the system and generate values for the othervariables. In this case, the fixed variables include the temperature ofthe fluid in connector S1 2004 (T_(S1)), the pressure of the fluid inconnector S1 2004 (P_(S1)), the change in pressure across valve V1 2006(ΔP_(V1)), the molar flow through connector S1 2004 (F_(S1)), thevolumetric flow through drum D1 2010 (Q_(D1)), and the change inpressure across valve V2 2014 (ΔP_(V2)). When these variables are set tofixed values, the solver will be able to solve the equations for therest of the unsolved variables. The solving process is described ingreater detail below. Included in that process is a method fordetermining which variables should be fixed and which should be free.

Eventually, the user will want the simulation model to predict actualbehavior and flowrates based on pressure differences. To do thisrequires additional variables and corresponding mathematical equationsin the simulation model to represent some of the physical detail. Someof these equations are called sizing equations because they relate somephysical or geometrical quantity to an operating variable.

These sizing equations can be seen as augmenting the original set ofequations in FIG. 21. Along with the equation set 2120 for describingthe behavior of valve V1 2106, an additional sizing equation 2126 hasbeen included. With the additional equation 2126, new variables areadded as well, including A_(V1), which is the cross sectional area ofthe valve V1 2106, and C_(V1), which is a sizing coefficient that stemsfrom the size and style of valve V1 2106. Drum D1 2110 has an additionalsizing equation 2128 that includes a new variable V_(D1), which is thevolume of the drum D1 2110, and τ_(D1) representing a residence time forfluid in the drum D1 2110. Valve V2 2114 has an additional sizingequation 2128 that includes A_(V2), which is the cross sectional area ofthe valve V2 2114, and C_(V2), which is a sizing coefficient that stemsfrom the size and style of valve V2 2114.

The inclusion of the sizing equations adds three new equations to thetotal set of equations and six new variables, so three of the variablesmust be fixed. In this case, the cross sectional areas of the valves,A_(V1) and A_(V2) are fixed, as is the residence time for fluid in thedrum, τ_(D1).

The simulation is still flow-driven steady-state. The additional fixedvariables are used to calculate the valve constants for the valves(C_(V1) and C_(V2)) and the volume of the drum (V_(D1)) based on thesupplied residence time. This mode of calculating sizing variables fromoperating data is sometimes called sizing mode.

With some physical details now available, the mode can now be changed toFluid Flow mode (or from sizing mode to equipment rating mode). Thecalculation is still steady-state, but instead of specifying theflowrate F_(S1) (as was done in design mode above) the boundarypressures P_(S1) and P_(S4) are specified instead; F_(S1) will becalculated. In addition, instead of specifying pressure drops across thevalves, these can now be calculated from the valve constants. Thesevalve constants were calculated from the previous steps, and now theirvalues can be “fixed”.

FIG. 22 shows the same system as FIG. 21, but the fixed variables havebeen changed to reflect the change to Fluid Flow mode. The bolded, fixedvariables now include T_(S1), P_(S1), A_(V1), C_(V1), Q_(D1), A_(V2),C_(V2), and P_(S4). In the previous mode, the valve constants (C_(V1)and C_(V2)) were calculated, and can now be used as fixed variables tosolve for other variables. In this case, the equations can be used tosolve for flowrates through the connectors (F_(S1), F_(S2), etc.) andfor the residence time of fluid in the drum D1 2210. The equations areidentical; only the fix/free status of some variables has been changed.

The previous calculations have all been at steady-state. In order toprepare for dynamic simulation, an additional step may be necessary.This step involves introducing the additional equations required fordynamic simulation and then solving the equations in steady-state mode.This system has been solved at steady-state and all variables now haveinitial values that can be used for actual dynamic simulation. Thesystem may calculate these initial values automatically in Fluid Flowmode so that they are always available; this would eliminate the needfor an additional explicit “Dynamic Initialization” step.

FIG. 23 shows the same system as FIG. 22 but with additional equations2332 for the “Dynamic Initialization” step. It also includes a flowdevice 2334 which interacts with valve V1 2306 and connector S1 2304 anda pressure device 2336 which interacts with drum D1 2310 and valve V22314. These two devices may use sensors to detect levels in theconnector S1 2304 and drum D1 2310 and in response, open or close thevalves V1 2306 and V2 2314. The new equations 2332 add three equationsto the total equation set and three new variables (M_(D1), E_(D1), andU_(D1)) to the total variable set. There must still be nine fixedvariables in order to solve for the remaining variables. The samevariables as in FIG. 22 are fixed. The “Dynamic Initialization” stepallows the system to use the known values from the steady-statecalculations to determine initial values of the dynamic variables andequations. This will give the dynamic mode calculations a starting placewhen the system fully switches into dynamic mode.

FIG. 24 demonstrates the final change to full pressure-driven, dynamicsimulation, which involves adding the time derivatives. In this simplesystem, the only addition is the holdup in drum D1 2410. Notice that thefirst two equations for the drum no longer equate to zero, but rather toderivative functions of M_(D1) and E_(D1). This change reflects that, ina dynamic simulation, the flows into and out of the drum D1 2410 willchange over time. At this point, as shown in FIG. 24, a singlesimulation model has been converted from steady-state flow-driven todynamic pressure driven by adding (or activating) additional equationsand changing the fix/free variable settings for the participatingvariables. The underlying simulation equations have remained the samethroughout the conversion.

At this point, some design principles can be identified. Theuncontroversial principle is that the models used are written in adeclarative language with control over which equations are active andwhich variables are defined as fixed. Equations support“categorization”. For example, the simulation user should be able toturn on (or off) all “sizing equations” in one action. This implies thatthe actual sizing equations are categorized as such. Another potentialuse for “categorization” is to enable/disable the dynamic equations. Ifthis can be done purely by analysis of the equation then this would notbe required.

Parameters also allow categorization. For example, Parameters can becategorized as “design” parameters or “operating” parameters. Designparameters can be categorized as “conductance”, “heat transfer”, and“capacitance”. This categorization can be used to consolidate queriesand cross checks for entering a new simulation mode. Parameters can alsobe categorized as “View”, “Edit”, “Advanced Edit”, and so on. Thisinformation can be used by the User Interface for filtering. Parameterscan also be categorized into “groups”. This information can be used bythe User Interface for filtering and grouping. System-defined defaultsfor “residence time” and related quantities used for system-generatedestimates are customizable. For example, a customer company may want touse a different default for their projects.

Aspects of the invention related to a solving simulations feature. FIG.25 is a flow chart describing the process of a simulation equationsolving technique 2500 known as Solve on Sufficiency. Solve onSufficiency is intended to solve the process-mode problem (the set ofequations that make up the behavior of the models in the currentsimulation) constantly, as soon as a solvable set of equations andvariables is available. After an initial solution is obtained, Solve onSufficiency is intended to run immediately in response to any changes inthe problem specification. Solve on Sufficiency follows the flowchart inFIG. 25 each time to ensure that all equations are solvable or arecommendation is made to suggest how the equations might be madesolvable.

When a modification is made to a flowsheet (step 2502), the systemimmediately analyzes the flowsheet with respect to the modification todetermine if the new flowsheet settings render the flowsheet equationssolvable (step 2504). If it is found to be solvable, the system willsolve all the equations (steps 2510 and 2512) and return to thebeginning to wait for a new modification of the flowsheet. However, ifon step 2504, the system of equations of the flowsheet is not found tobe solvable, the system will determine if a subset of the equations aresolvable (step 2506). If not, the system moves on to step 2508 andrecommends variables in the system that the user should fix at certainvalues or free to allow the system to solve for them. For instance, ifthe system of equations is not solvable because there are more variablesto solve for than there are equations, the system may recommend that theuser set one or more variables to fixed points so that the system canuse the equations to solve for the remaining variables. However, if somevariables have been fixed in such a way as to render the equationsunsolvable, the system may recommend that one or more fixed variables befreed in order to enable the system to solve for the free variableswithout conflict.

Once the recommendations have been made and the user has fixed or freedone or more variables, the system goes back to step 2504 to determine ifthe system of equations is solvable for the current variable set. If so,the system will execute steps 2510 and 2512 and return to the beginningof the flowchart. If not, the system returns to step 2506 to determineif a subset of equations/variables are solvable. If so, the systemproceeds to step 2510 to solve the solvable subset of equations. In step2512, the system would determine that not all of the equations have beensolved yet and the system would move on to step 2508, suggesting theuser fix or free one or more variables. Once again, the system wouldthen analyze the equations for solvability after the one or morevariables have been fixed or freed by the user. This loop will continueuntil the system can satisfactorily solve all of the equations and doesso, returning to the beginning of the flowchart. This process occurs onevery modification of a flowsheet in order to ensure that the flowsheetbeing built is a useful representation of a solvable simulation.

The variables in the problem will have a “fixed/specified” or“free/calculated” attribute attached to them. If they are “fixed”, theywill have a numerical value in the corresponding UOM. Some variables mayhave upper and/or lower bounds defined on them. In process engineeringproblems, the variables are normally all continuous, but discontinuitiesshould be expected. The equations can be linear or nonlinear. Processengineering model equations are normally sparsely populated. They alsopossess a natural block-diagonal quality, especially if the equationsarising from each model are preserved in relative position. This will beexplained in more detail later.

The process-mode/steady-state problem is to find the values of the“free” variables so that every equation evaluates to zero residual orwithin a small tolerance. This can also be interpreted as solving amodel for its outputs, given its inputs. The system focuses on aparticular solving method using Solve on Sufficiency.

For example, upon instantiation of a “Sum” model in the flowsheet(assuming that it is the first model being instantiated), the client ispresented with the following closed-form equation:

C=A+B   (1)

Within the simulator, equations can also be represented in open-form (or“residual form”) as follows:

A+B−C=0   (2)

In the Solve on Sufficiency paradigm, this equation should be solvedimmediately. However, note that there is infinity of solutions to (1) or(2). The problem must be constrained sufficiently, so that there is aunique solution arising from (1) or (2).

The closed-form expression (1) is helpful in understanding theinformation flow. If A and B are specified (or “fixed”, or “input”),then C (the “free” variable, or “output”) is uniquely determined. Theopen-form equation (2) encapsulates the relationship between the threevariables and is flexible in terms of what variables can be fixed andwhat variables can be free. For example, B and C can be “fixed”, whilethe “free” variable A is computed (solved) to satisfy (2). Similarly, Aand C can be fixed while B is “free” to be solved to satisfy (2). Thefinal permutation is A and B can be fixed while C is free to be solvedto satisfy (2). Table 1 illustrates these combinations Fixed and FreeVariables for the Sum model.

TABLE 1 Fixed variable Fixed Variable Free Variable A B C A C B B C A

In this example, two variables need to be fixed to get a unique answer.This is related to the notion of degrees of freedom. Degrees of freedomcan be defined as the difference between the total number of variablesin the system and the total number of equations describing the system.Thus in the above example, there are 3−1=2 degrees of freedom. Whenthere are positive non-zero degrees of freedom, it implies that thesystem of equations may have infinity of solutions. A minimum number ofvariables must be specified (as fixed) so that there is a uniquesolution to the system of equations. The number of variables to specifyas “fixed” is equal to the degrees of freedom. The variables that arenot fixed are considered as free. Certain algorithms can be used toidentify variables that should be fixed or free.

In order to provide Solve on Sufficiency functionality, the followinghigh level tasks need to be performed:

-   -   i. Gather the equations and variables in the currently defined        context.    -   ii. Ensure that there is a solvable set of equations via the        recommendation of appropriate fixed and free variables.    -   iii. Apply algorithms that allow re-arranging of the equations        and variables, so that a lower triangular structure (see        equation-variable grids below) can be realized, as close as        possible. Such algorithms would take into account the cost of        tearing some variables.    -   iv. Group block-sets of equations as follows: (a)        singletons; (b) duals; (c) triads; (d) larger sets.    -   v. Further group each along linear or nonlinear sets. If linear,        note that the system only needs to do Lower Upper (LU)        factorization once.    -   vi. Define two solution mechanisms: (a) Gauss (explained        later)—which is amenable to strong parallelization; (b)        Gauss-Seidel (explained later)—which normally converges faster,        but is more difficult to parallelize, which would operate on        linear or nonlinear sub-problems.    -   vii. Use efficiency heuristics that would speed up subsequent        solve on sufficiency cycles.

Solvability analysis is required to identify structural singularity, ifany. Solvability is also the process of identifying fixed variables.Graph analysis methods are normally used to identify equation-variablepairs, so that the remaining variables can be classified as fixedvariables. In the described application, the user will identify somevariables as fixed variables. In such cases, analysis algorithms areused to ensure that such specifications do not cause false structuralsingularity, and in the event that they do flag such singularity, thealgorithms guide the user on what variables to free up so that thesystem is solvable. Additional analysis algorithms look for“over-specification”. If the user specifies too many variables or thewrong variables, it may no longer be solvable and the algorithmsidentify the problem and guide the user to free some of the variables.The system will also guide the user to setting fixed variables in theevent that an insufficient number of variables have been fixed. If thereare not enough fixed variables, the system of equations will possiblyhave more than one solution, and the system will be unable to solve forthe free variables.

Symbolic analysis is required to analyze the system of equations, andobtain row and column permutations so that a lower triangular structureemerges (see the incidence matrices below). In doing so, tear variablesalso emerge. Tear variables appear above and to the right of thediagonal of the triangle structure and cannot be solved for in the samemanner as the variables within the triangle structure. A lowertriangular structure is critical to obtaining an inexpensive solutionsequence that side-steps the need for a large simultaneous solution.There exist several algorithms to perform such triangularization. Awell-known graph algorithm used for the purpose is the Dulmage &Mendelsohn algorithm for maximal matching on a bipartite graph.Algorithms for triangularization should ideally be able to obtainmaximal matching, minimizing the number of tear variables, be able toaccommodate the quality of the tear streams in the analysis (the minimalset of tear variables may have high sensitivity, and confer poorconvergence properties; the algorithms used must understand the cost ofpoor convergence), and be able to get tear variables close to 2×2 or 3×3blocks, so that a poorly reconvergent stream can be absorbed in ahigher-order block easily. Ideally, a system of equations will bereordered into a perfect lower triangle structure with all 1×1 blocks.This would result in sequentially calculating for each variable in alinear manner. Other blocks, like 2×2 or 3×3 may require simultaneouscalculation, which is not as efficient as sequential calculation.

The lower triangular structure provides the solver with the sub problemsthat can be solved. These can be 1×1 blocks, or 2×2 blocks, or 3×3blocks, or higher blocks. In the event that convergence is hard to comeby, (because of the presence of tear variables that are treated aniteration-step behind the variables being iterated upon) the solvershould be able to identify and dynamically group larger sets ofequations for simultaneous solution. In the ultimate limiting case, theentire set will be solved as one big set of equations.

The solver is able to identify larger blocks as linear or nonlinear. Thesolver can cluster/group sections of linear equations together, ifpossible, so that it can do one Lower Upper (LU) Decomposition at thestart of a solve on sufficiency, and keep the decomposition for allsubsequent solutions for efficiency purposes, until such time thestructure changes.

After successful triangularization, the solver will have a sequence oflinear and nonlinear blocks where the variables obtained in the upstreamsolution sequence flows down the block-triangular structure. When thesolver encounters a tear variable, it uses the old value (oneiteration-step behind) of such variables, until such time the variableis updated in the triangular structure.

As understood by one of ordinary skill in the art, the Gauss paradigmrequires that at the current iteration, old variable values be used toupdate to the new variable values. However, the newly computed variablevalues are not used in the triangle-cascade for that iteration. Instead,the new values are used at the start of the next iteration cycle. Such aseparation in iteration of the data-flow computation allows parallelismto a very high degree, because all blocks are fully specified in termsof their old values and block-structure, and can independently obtainthe new value of the variables that each block is “responsible” for. Thedownside of Gauss paradigm is a reduced convergence rate sometimes inrelation to Gauss-Seidel.

The Gauss-Seidel paradigm requires that as soon as a variable is updatedduring the triangular navigation, it is used immediately in thesubsequent calculations during that iteration itself. Sometimes it makessense to use such a paradigm; if the solver has an updated variablevalue, why not use it to get better values of variables downstream inthe triangular-cascade? This can sometimes give a faster convergencerate. The downside of this is that it offers less scope for parallelism.

The various functional steps in the operation of the analyzer areoutlined in this section with a summary of the interface requirementsfor input data and output data. Each step in the process should bedesigned with an appropriate code interface so that differentimplementations can be exchanged without extensive re-coding.

Referring first to generating equations for analysis (flattening), thefirst step in analysis is to convert the editable simulation structure(flowsheets, model instances) into a set of numerical equations. This isdone by starting at the top level root flowsheet and recursivelyreplacing each model instance with the equations it introduces to thesystem. Since model types in the library may be parameterized, theprocess of equation generation involves applying current values ofparameters, such as the number of thermo components in use, or theconditional inclusion of a sub-model such as a heat loss calculation orcompressor head-flow curve. This naturally means that changing aconfiguration parameter may change the number and type of equations inthe system while keeping the same flowsheet topology.

There is a transformation from the “edit” space to the “solver” space.For example a variable in the editable database may be a rich datastructure with many attributes including value, whereas a variable inthe solver environment may be a simple double stored in an array forefficient access.

Referring now to partitioning equations into solvable and unsolvable,before any attempt can be made to solve the equations generated from themodel they must be checked for consistency and valid specification.Specification problems may include groups of equations that have toomany unknown variables for solution (“underspecified”) or groups ofequations that have too few variables for solution (“over specified”).Both situations may occur at the same time. It is natural for incompletespecifications to occur as a simulation is being constructed and thegoal of this step is to ensure the system does not try to solveequations that are not yet ready for solution. Solvable and unsolvableequations follow separate paths in the following steps.

In technical terms this process is known to those skilled in the art asa coarse Dulmage-Mendelsohn decomposition. It separates equations intosolvable and unsolvable, and gives information about the under or overspecified status of the unsolvable equations. Some post processing isrequired after the Dulmage-Mendelsohn decomposition to extract the exactinformation needed.

The input to this step is the “incidence matrix”, the complete list ofequations in the simulation and the record of which unknown variablesappear in which equations. The output consists of two separate lists ofequations, those which are solvable (maybe none) and those which areunsolvable (should be none when the simulation is properly specified).When there are unsolvable equations the output contains two sub-lists ofequations and variables giving more information about the problem:equations and variables forming a smallest underspecified group andequations and variables forming a smallest over specified group.

Fixing any free variable in the underspecified group will improve thespecification of the system, while freeing up any fixed variable fromthe equations in over specified group will also improve thespecification of the system. For illustration, consider the followingsystem as shown in Table 2, below:

TABLE 2 Variables Equations 1 2 3 4 5 6 7 8 9 10 11 1 X 2 X X X 3 X X 4X 5 X X X X X 6 X X X X 7 8 X X X X X X 9 X X 10 X 11 X X 12 X X

Applying the Dulmage-Mendelsohn decomposition to this system producesthis result as shown in Table 3, below:

This shows that equations 2, 3, 9, 11 are well specified with respect tovariables 1, 3, 10, and 7 as shown in the middle block and can proceedto solution, while the other equations 6, 8, and 5 and the otherequations 4, 12, 10, 1, and 7 need specification changes before they canbe solved. The left block for equations 6, 8, and 5 is under specifiedand the right block for equations 4, 12, 10, 1, and 7 is over specified.Next, consider a small modification to the above example so that thedecomposition looks like this as shown in Table 4, below:

Note how variables 6 and 8 now appear in equations 9 and 11 in themiddle block. This means that equations 9 and 11 cannot actually besolved since variables 6 and 8 are over determined. In reality theinterpretation should be as shown in Table 5, below:

This means that there are no solvable equations at all in this system.This result is arrived at by crossing out equations 9 and 11, and thencrossing out all variables involved in those two equations, whichresults in crossing out all of the variables.

According to an embodiment of the invention, the simulation programidentifies unsolvable steps. In the prior step, the equations in thesystem were partitioned into solvable and unsolvable groups. Theequations in the unsolvable groups (left and right blocks of Tables 3and 4 and both blocks of Table 5 above) now follow a different path fromthe solvable equations. They cannot be solved right away, so the systemmust guide the user to make them solvable.

Preferably, in every case where unsolvable equations exist the systemadvises on specification changes to bring all the equations into thesolvable group. The system does this by highlighting fixed, specifiedvariables that may be freed, or free, calculated variables that may bespecified. If the user makes any single recommended change it willimprove the system overall, and since our user can only make one changeat a time the system will repeat the analysis after each specificationchange and guide the user until the whole system becomes solvable.

Considering the current example, the advice given to the user would bethat any variables among 2, 4, 5, 9 or 11 are candidates for specifying(fixing), and any fixed variables appearing in equations 1, 4, 7, 10 or12 are candidates for freeing.

One special case exists where all variables are fixed in an equation andtherefore such an equation has no free variables and will drop out ofthe analysis. In this case it is simply necessary to advise on freeingany of the fixed variables in such an equation in order to bring it intoplay.

Further, the simulation program of this embodiment addresses solvablesteps. Every simulation will contain many link equations and connectionequations of the form x=y. These are redundant from a solutionperspective and can be eliminated from the problem presented to thesolver. To do this efficiently, the solver lets x and y be representedby the same solver variable and arrange that the names “x” and “y” bothrefer to the same storage. Special consideration must be given to caseswhere one of x or y are specified (the other variable vanishescompletely), or when x and y have different min and max values (perhapsthe most constraining min and max between both should be used).

When a problem is first presented to the solver it may look as if it isa large set of simultaneous equations. Consider for example the systemshown in Table 6, below:

TABLE 6 Variables Equations 1 2 3 4 5 6 7 8 9 10 1 X X X X 2 X X X X X XX X 3 X X 4 X X X X X X 5 X X X X X X X 6 X X X X X X X 7 X X 8 X X X X9 X X X X X X X X X 10 X X X

When this system is presented to the partitioning step, the result is asshown in Table 7, below:

The system is square and potentially solvable since it has entries allalong the leading diagonal. However, a further sequence of row andcolumn permutations can reduce the system to the form shown in Table 8,below:

Instead of one large block, the problem has been reduced to thesequential solution of five smaller blocks. This results in increasedrobustness, faster solution and reduced memory usage. This operationfollows on naturally from the Dulmage-Mendelsohn partitioning step andis known variously as reduction to block lower triangular form or thefine decomposition of Dulmage-Mendelsohn. A commonly known efficientalgorithm for this is Tarjan's algorithm. The solver uses this operationto extract the inherently sequential nature of many simulation problems.

Dynamic simulation according to an embodiment of the invention requiresa differential equation solver, or more precisely adifferential-algebraic equation solver (DAE solver). Such a solver isbuilt on the principles of the steady state solver and uses all of thesame elements.

Analysis (and solution) proceeds by transforming the differentialequations into algebraic equations and then following the same path asin the earlier sections. There is a small variation to account for statevariables and time derivatives, but this is easily incorporated.

The process is probably best explained by example. FIG. 26 shows asimple system diagram 2600 for use with the following exampleexplanation. The diagram 2600 consists of a flow input 2602, a pressurenode 2604, a second flow 2606, a valve 2608, and an output 2610. Simpleequations can be written for use in describing the analysis principles:

For the pressure node 2604:

der(M)=Fin−F

P*V=M*R*T

rho*V=M

For the valve 2608:

Q*rho=F

Q=K*sqrt(P−Pout)

For the example, Fin, V, R, T, K & Pout are fixed to certain values.That leaves five equations in the five unknown variables M, F, P, Q &rho.

In steady state, all time derivatives are zero, so der(M) is set tozero. The incidence matrix looks as shown in Table 9, below:

TABLE 9 Variables Equations 1 2 3 4 5 1 X 2 X X 3 X X 4 X X X 5 X X

After re-ordering the rows and columns for solution the matrix are asshown in Table 10, below:

The solver can solve for F=Fin, but after that it must to solve theremaining four equations simultaneously.

For dynamic simulation in accordance with aspects of the invention, thesolver needs a way to evaluate the der(M) function. This is done byadding a new variable dMdt to hold the time derivative, and thenintroducing a system defined equation to evaluate this derivative. Theresult is like this:

For the pressure node 2604:

dMdt=Fin−F

P*V=M*R*T

rho*V=M

For the valve 2608:

Q*rho=F

Q=K*sqrt(P−Pout)

Extra time derivative equation for each state variable:

dMdt=(M−M0)/dt

The function der(M) is replaced internally with the value of dMdt, andthen dMdt is defined by an equation that the system generates accordingto the kind of integrator in use. In the example above a simple backwarddifference is used for implicit Euler. The quantity M0 is the value of Mfrom the previous time step (the system accounts for this internally anddoes not display it to the user).

Applying der(M) to the variable M turns M into a state variable. InDynamic mode the system cannot allow state variables to be specified bythe user or it will be impossible to integrate them. Therefore no checkbox must be shown next to M or dMdt. These values are always calculated.

In an embodiment, dMdt is included as variable 6 and the new equation asequation 6. The incidence matrix is as follows in Table 11:

TABLE 11 Variables Equations 1 2 3 4 5 6 1 X X 2 X X 3 X X 4 X X X 5 X X6 X X

When analysis is applied to the equations, the result is shown in Table12, below:

In this example, all equations need to be solved simultaneously. This istypical of implicit integration methods; they tend to cause largesimultaneous blocks of equations.

Referring now to a Solver feature of the present invention, once theanalysis is complete the numerical integrator can be applied to thesystem. The process follows the following steps:

-   -   i. Set the initial values of all variables at time zero to the        steady state solution    -   ii. Advance time by one time step    -   iii. Fix M0 at the value from the previous time step    -   iv. Solve the equation set for new values of the algebraic        variables and the state(s)    -   v. Return to step ii and repeat

The process of solving the equation set in step iv will use the samesimultaneous equation solver as described in the Unsolvable Stepssection.

For purposes of illustration, programs and other executable programcomponents, such as the operating system, are illustrated herein asdiscrete blocks. It is recognized, however, that such programs andcomponents reside at various times in different storage components of acomputing device, and are executed by a data processor(s) of the device.

Although described in connection with an exemplary computing systemenvironment, embodiments of the aspects of the invention are operationalwith numerous other general purpose or special purpose computing systemenvironments or configurations. The computing system environment is notintended to suggest any limitation as to the scope of use orfunctionality of any aspect of the invention. Moreover, the computingsystem environment should not be interpreted as having any dependency orrequirement relating to any one or combination of components illustratedin the exemplary operating environment. Examples of well-known computingsystems, environments, and/or configurations that may be suitable foruse with aspects of the invention include, but are not limited to,personal computers, server computers, hand-held or laptop devices,multiprocessor systems, microprocessor-based systems, set top boxes,programmable consumer electronics, mobile telephones, network PCs,minicomputers, mainframe computers, distributed computing environmentsthat include any of the above systems or devices, and the like.

Embodiments of the aspects of the invention may be described in thegeneral context of data and/or processor-executable instructions, suchas program modules, stored one or more tangible, non-transitory storagemedia and executed by one or more processors or other devices.Generally, program modules include, but are not limited to, routines,programs, objects, components, and data structures that performparticular tasks or implement particular abstract data types. Aspects ofthe invention may also be practiced in distributed computingenvironments where tasks are performed by remote processing devices thatare linked through a communications network. In a distributed computingenvironment, program modules may be located in both local and remotestorage media including memory storage devices.

In operation, processors, computers and/or servers may execute theprocessor-executable instructions (e.g., software, firmware, and/orhardware) such as those illustrated herein to implement aspects of theinvention.

Embodiments of the aspects of the invention may be implemented withprocessor-executable instructions. The processor-executable instructionsmay be organized into one or more processor-executable components ormodules on a tangible processor readable storage medium. Aspects of theinvention may be implemented with any number and organization of suchcomponents or modules. For example, aspects of the invention are notlimited to the specific processor-executable instructions or thespecific components or modules illustrated in the figures and describedherein. Other embodiments of the aspects of the invention may includedifferent processor-executable instructions or components having more orless functionality than illustrated and described herein.

The order of execution or performance of the operations in embodimentsof the aspects of the invention illustrated and described herein is notessential, unless otherwise specified. That is, the operations may beperformed in any order, unless otherwise specified, and embodiments ofthe aspects of the invention may include additional or fewer operationsthan those disclosed herein. For example, it is contemplated thatexecuting or performing a particular operation before, contemporaneouslywith, or after another operation is within the scope of aspects of theinvention.

When introducing elements of aspects of the invention or the embodimentsthereof, the articles “a,” “an,” “the,” and “said” are intended to meanthat there are one or more of the elements. The terms “comprising,”“including,” and “having” are intended to be inclusive and mean thatthere may be additional elements other than the listed elements.

In view of the above, it will be seen that several advantages of theaspects of the invention are achieved and other advantageous resultsattained.

Not all of the depicted components illustrated or described may berequired. In addition, some implementations and embodiments may includeadditional components. Variations in the arrangement and type of thecomponents may be made without departing from the spirit or scope of theclaims as set forth herein. Additional, different or fewer componentsmay be provided and components may be combined. Alternatively or inaddition, a component may be implemented by several components.

The above description illustrates the aspects of the invention by way ofexample and not by way of limitation. This description enables oneskilled in the art to make and use the aspects of the invention, anddescribes several embodiments, adaptations, variations, alternatives anduses of the aspects of the invention, including what is presentlybelieved to be the best mode of carrying out the aspects of theinvention. Additionally, it is to be understood that the aspects of theinvention is not limited in its application to the details ofconstruction and the arrangement of components set forth in thefollowing description or illustrated in the drawings. The aspects of theinvention are capable of other embodiments and of being practiced orcarried out in various ways. Also, it will be understood that thephraseology and terminology used herein is for the purpose ofdescription and should not be regarded as limiting.

Having described aspects of the invention in detail, it will be apparentthat modifications and variations are possible without departing fromthe scope of aspects of the invention as defined in the appended claims.It is contemplated that various changes could be made in the aboveconstructions, products, and process without departing from the scope ofaspects of the invention. In the preceding specification, variouspreferred embodiments have been described with reference to theaccompanying drawings. It will, however, be evident that variousmodifications and changes may be made thereto, and additionalembodiments may be implemented, without departing from the broader scopeof the aspects of the invention as set forth in the claims that follow.The specification and drawings are accordingly to be regarded in anillustrative rather than restrictive sense.

What is claimed is:
 1. A system for simulating a process entitycomprising: a processor; a memory device coupled to the processor;software instructions stored on the memory device and executable by theprocessor, said instructions comprising: instructions for creating aplurality of entity type objects, said entity type objects genericallyrepresenting a type of process entity; instructions for storing theplurality of entity type objects in a shared repository; andinstructions for enabling a plurality of users to access the pluralityof entity type objects in the shared repository simultaneously.
 2. Thesystem of claim 1, wherein the users are enabled to access the entitytype objects from a plurality of locations.
 3. The system of claim 1,further comprising instructions for storing changes made to the entitytype objects by any of the plurality of users in the shared repositoryfor use by another of the plurality of users.
 4. The system of claim 1,wherein storing the plurality of entity type objects comprises importingan externally created entity type object into the shared repository. 5.The system of claim 1, further comprising instructions for storingsimulations in the shared repository, said simulations comprisingflowsheets and instances of a plurality of entity type objects.
 6. Thesystem of claim 5, further comprising instructions for saving a snapshotof a simulation stored in the shared repository, said snapshotrepresenting an archive of a simulation.
 7. One or more tangible,non-transitory computer-readable media having executable instructionsstored thereon that, when executed, perform a method of simulating aprocess entity comprising: creating a plurality of entity type objects,said entity type objects generically representing a type of processentity; storing the plurality of entity type objects in a sharedrepository; and enabling a plurality of users to access the plurality ofentity type objects in the shared repository simultaneously.
 8. Thecomputer-readable media of claim 7, wherein the users are enabled toaccess the entity type objects from a plurality of locations.
 9. Thecomputer-readable media of claim 7, wherein the method further comprisesstoring changes made to the entity type objects by any of the pluralityof users in the shared repository for use by another of the plurality ofusers.
 10. The computer-readable media of claim 7, wherein storing theplurality of entity type objects comprises importing an externallycreated entity type object into the shared repository.
 11. Thecomputer-readable media of claim 7, further comprising storingsimulations in the shared repository, said simulations comprisingflowsheets and instances of a plurality of entity type objects.
 12. Thecomputer-readable media of claim 11, wherein the method furthercomprises saving a snapshot of a simulation stored in the sharedrepository, said snapshot representing an archive of a simulation.
 13. Aprocessor executable method of simulating a process entity comprising:creating a plurality of entity type objects, said entity type objectsgenerically representing a type of process entity; storing the pluralityof entity type objects in a shared repository; and enabling a pluralityof users to access the plurality of entity type objects in the sharedrepository simultaneously.
 14. The method of claim 13, wherein the usersare enabled to access the entity type objects from a plurality oflocations.
 15. The method of claim 13, further comprising storingchanges made to the entity type objects by any of the plurality of usersin the shared repository for use by another of the plurality of users.16. The method of claim 13, wherein storing the plurality of entity typeobjects comprises importing an externally created entity type objectinto the shared repository.
 17. The method of claim 13, furthercomprising storing simulations in the shared repository, saidsimulations comprising flowsheets and instances of a plurality of entitytype objects.
 18. The method of claim 17, further comprising saving asnapshot of a simulation stored in the shared repository, said snapshotrepresenting an archive of a simulation.